A multi-master database cluster, which does not employ distributed locking to protect data access, has to detect and resolve write conflicts of transactions at a later time, eventually before the transactions are committed. Such database clusters typically employ Optimistic Concurrency Control (OCC) for data replication and synchronization purposes, and sort out write conflicts usually by rolling back transactions.
A conflict may arise when two or more transactions perform a write access to a same database object through separate database servers substantially concurrently. The phrase “substantially concurrently” may be defined as a situation where a first transaction is executed at a first database server and a second transaction is executed at a second database server, and the timing of both the executions is such that the first database server does not have knowledge of the second transaction and/or the second database server does not have knowledge of the first transaction.
In order to resolve the conflict, the database cluster needs to abort and roll back all but one of the two or more transactions. Such rolling back of transactions affects an overall transaction processing performance of the database cluster. Moreover, roll-backs are a waste of efforts, as rolled back transactions have to be processed again at a later time.
Moreover, in a situation where a database schema of the database cluster includes a particular database table to which several transactions need to write frequently, that particular database table is referred as a hot-spot in the database schema. Such hot-spots often lead to frequent occurrence of conflicts in the database cluster. If hot-spots are too pronounced, the overall transaction processing performance of the database cluster can be seriously degraded.
Moreover, for some applications, avoiding conflicts may be a necessary requirement, if these applications are unable to handle an unexpected abortion of database transactions in a logical manner.